I'll deal with that asap.

Just a question: what's the rational for accessing this protected field? The risk being that the channel is closed outside of the logical flow

Once I get hold of it, I can check if it is a SocketChannel and do further introspection on it.

For some of our tests, I can change the state of the SocketChannel and make ensure our upstack code can recover from various unexpected and bad states.

OTOH, if you know you are dealing with a NioSocketSession, you know for sure it's a SocketChannel.

Sure there are missing functions that would give you back the underlying channel status (like isChannnelConnected() or such), but well, I get your requirement, and it's simpler to make the function public.

We can debate it if we should give access to the channel state instead of giving full access to the full channel, because that would allow any application to write/read/shutdown it, which IMHO opens the door a bit wide.

Just let me know what you think of it, to see if there is some means to do that and have your app happy at the same time.

In the mean time, patch applied.

I don't think we need to expand the public API footprint beyond that.
I need the actual socket channe object for one kind of test where we forcibly reset the socket channel state without actually closing it. All connections live a Commons Pool pool.